The present invention is related generally to computers. More specifically, the present invention is related to debugging software for debugging computer code.
Computers have a history and current scope extending much further than the personal computers which are more visible to the general public. Mid-range and large mainframe computers are far from obsolete, having many advantages over personal computers. Some advantages can include well tested operating systems, special purpose operating systems, robust fault tolerant operating systems, multiple processor support, redundancy support, reliability, real time operating systems, high throughput transaction processing support, multiple busses, and built in support for database management functionality.
One example of mainframe use includes transaction processing for banking transactions, automatic teller machine transactions, and electronic commercial transactions. Transaction processing requires robust, accurate, and predictable execution of tasks to avoid performing a task more or less than the desired number of times in the case of a failure. Real time processing can require graceful degradation of services when a component fails. Many of these features are promised for personal computers but have not been delivered, as evidenced by less than graceful and less than infrequent personal computer hangs and crashes.
Over a long period, even 20 or 30 years, many utilities and tools have been developed and incrementally improved upon to aid the users and vendors of such legacy computers. One set of tools includes simulators and debuggers. Simulators can simulate the execution of computer code, including machine code. Sometimes it is advantageous to provide a simulator a legacy computer to simulate the execution of the native machine code, rather than running the code directly on the legacy computer.
Simulation or emulation often involves step-by-step simulation of execution of native machine code by a typically larger number of machine code instructions. For example, 4 bytes of machine code, 0106 A34F, representing LOAD REGISTER 6 with the literal 16 bit hex number A34F may be simulated by 2 lines of a higher level language such as xe2x80x9cCxe2x80x9d and executed by 50 bytes of machine code. The simulator may include routines for accepting the machine code 0106 A34F and decompiling to generate a text string such as xe2x80x9cLDIR6 0xA34Fxe2x80x9d. The text string generation can provide a meaningful text string for any human using the tools. A compiler having symbolic debugging support can generate a cross-reference table relating high level source code to machine code.
Single-stepping a mainframe can be highly impractical, given the number of users normally supported. Even momentary use of an actual machine, having the state saved and restored, can require momentary use of the entire machine as the task to be debugged is single-stepped through one machine instruction. This can require a relatively large amount of overhead to save the entire machine state, execute one machine instruction, and restore the machine state. By using a simulator, the simulation task can be run as any other, non-privileged task, as the actual CPU and memory is not being executed, only a simulated version of the CPU and memory. Thus, even when machine code is being debugged on the same machine on which it is eventually to be run, use of a simulator allows for less intrusive access to the machine, which may be running other tasks.
Personal computers and workstations are ubiquitous and relatively inexpensive compared to legacy computers. The large numbers of machines sold creates a market enabling large numbers of software titles to be sold. In particular, pleasing and user friendly graphical window systems and graphical user interfaces (GUIs) have been developed and the cost spread over several million machines and computer programs sold. The large personal computer market makes development of programming and debugging tools economically feasible. In particular, symbolic debuggers and simulators having pop-up windows have been developed for personal computers and workstations. Debugging and single-stepping of computer programs can be performed in a cubicle on an inexpensive personal computer, and the results saved into files and even e-mailed or shared on a network, using other tools commonly found on a personal computer.
In contrast, debugging and simulator tools written for legacy computers have not been able to take advantage of the large number of tools for the personal computer. For example, a financial transaction processing mainframe typically does not run compatible with the Microsoft Windows(trademark) operating system. While a windows type environment could be developed for the mainframe, the cost would have to be spread over a smaller number of machines and would not likely be a high priority project in any case. While a mainframe compiler and simulator could be developed to generate and simulate mainframe machine code on a personal computer, the cost would have to be spread over a small number of users, likely internal users. Such a product is not likely to be developed due to lack of market interest and market priorities.
What would be desirable therefore, is a system for utilizing existing personal computer tools and GUIs in combination with existing mainframe compilers, symbolic debuggers, and simulators. What would be advantageous are methods and software tools for debugging mainframe computer code on a personal computer or workstation using debugging tools residing on the mainframe.
The present invention includes a system for simulating a computer program in a first computer while controlling the simulation in a second computer. The first computer can include a compiler for compiling a high level source language module to a machine code binary module and a decompiler for decompiling the machine code binary module into human readable computer machine language text. The computer machine language can also be referred to as assembly language or a register transfer language. The computer machine language text can be assembled into the machine code binary in some embodiments and exists only for human reading in other embodiments. In some cases, the high level source language is compiled into a machine language, and is then compiled into a machine code binary. In these embodiments, a decompiler may not be desired unless decompilation to computer machine language on the fly is desired.
The first computer can also include an interactively driven simulator-debugger capable of simulating or emulating the execution of the machine code instructions in the machine code binary module. The simulator-debugger preferably includes a message receiver for receiving externally generated commands for controlling the simulator. Commands can include commands referencing either high level source language position, machine language position, or machine code binary position. In one embodiment, commands can be received referencing either high level language position or computer machine language position and respond in both high level language position and machine language position. This can enable windows displaying either high level or machine language to follow the simulated execution of the machine code binary. In one application, break point positions are received in either a high level language position or a machine language position, and, after the breakpoint is set, the status is reported back referencing both high level and machine language positions.
Preferably, a graphical user interface (GUI) is used to generate computer display windows including a high level language debugging window, a machine language debugging window, and a batch command window, primarily for initiating file transfers and loading of the simulator-debugger. In one embodiment, the GUI resides on the same computer as the simulator-debugger. In another embodiment, the GUI resides on a computer different from the computer executing the simulator debugger. In a preferred embodiment, the simulator-debugger executes on a high performance mainframe computer and the GUI resides on a generic personal computer or workstation. The first and second computers can be coupled through communication links to provide for interactive debugging and file transfer.
In one illustrative method, a high level source file is compiled on a first computer to a machine code binary module, and the machine code binary module is decompiled to a human readable machine language module. In some embodiments, the decompiler can operate in a batch mode to produce an entire file of machine language text or in an on-the-fly mode to generate the machine language corresponding to a currently executing machine code instruction. Preferably, a data structure is created having a mapping between machine code binary positions, machine language positions, and high level language positions.
In an illustrative debugging method, commands are sent from a second computer such as a workstation to a first computer such as a high performance mainframe. High level language source code can be edited on either the first or the second computer and transferred to the first computer. Commands can be sent from the second computer to the first computer to initiate the compilation, decompilation, and/or simulation. Once begun, the simulation-debugging can be controlled and monitored from either a high level language window or a machine language window in the second computer. In a preferred embodiment, the execution can be single-stepped or breakpointed from either the machine language window or high level language window and followed in both the high level language window and the machine language window.